Why 7 if we can do it with 3
Least privileged access is to have nothing more than the permissions you need to complete your task.
Every time I get to a new customer, and I need administrative access to the environment, I just get Domain Admin. We could justify this action by going into my background…
The years of experience, because…
Well, on reality there is a much important fact: there is no clear “Least Privileged Access” strategy. Is way easier to just give away domain admin rights. This is not because of trust issues. Of course, we trust our administrators, but this is not reason enough to give full access to all the environment.
Then, why does this identity exist (either the Admin user or the group)? Easy, for initial setup and very (but very) limited tasks that cannot run under specific delegations. When we first setup a server, with a brand-new Domain Controller, the Administrator account has all required rights to do anything we want. And of course, we want to setup the least privileged access to anyone who uses this environment.
Neuron fight result… an idea
There is a well-know old term, called “Least Privileged Access”, but what does this mean? What it “really” means? Many of the domains, if not all, I have gotten access to, have all their administrators as permanent members of the Domain Admins group (or Enterprise Admins or the Built-In administrators). This renders into too much privileges granted.
We always have to keep this number to a minimum, and to do that, we have to “design” our privileged access strategy. By analyzing the requirements of each party who needs administrative access to our domain.
Let’s take as an example the built-in “Account Operators” group. This group can manage any user and/or group within the domain, except for the Administrators (user and Group). In a very simple environment, this role could be enough. But if you decide to follow best practices, you already have a Privileged/Semi-Privileged/Non-Privileged user strategy; and guess what? The Account Operators group has the right to change not only the Non-Privileged Users (normal, standard users), but also Semi-Privileged Users and Groups. This is not a clever idea.
If we can properly identify these specific roles, within all the teams and persons who make changes into our Active Directory, then we could delegate the minimum amount of permissions and rights to each group. In the example above, we would create a more restrictive role that is only able manage Non-Privileged users. Additionally, we will create another separated role, which can only manage non-privileged groups.
What would I do if I’m working for you
Knowing the environment is always a “must do”, but even more in this case, is the only way to identify the tasks that each group of users must do.
Start with the most privileged groups (Enterprise Admins, Domain Admins and Administrators), and understand the tasks they are executing. Indeed are, at least some, unique tasks that only a privileged user can run, like promoting a Domain Controller. But most of the time, these highly privileged tasks are not executed every day, or week, or month. Depending on the size of the environment, can go from 1 or 2 per year in small environments up to 15 or 20 in big ones. This does not justify being carrying around these privileges for everyday use.
Once identified the tasks (or most of the “every-day” tasks), we can group them together, giving place to a new role. Roles, or the group of tasks earlier mentioned, can be dynamic, meaning that the role will be empty most of the time, and assigned only when needed.
Building the plan
Once finished all the Built-In groups, and identified all the tasks (daily ones and once-in-a-while ones) we have a clearer understanding of who needs to do what. Having this information, we can increase the overall security of our domain, because people is doing what they need to, but no more than that. Under this scenario, if an account gets compromised, limiting the damage to that account has being grant to do, and nothing more..
Now that we have understood the Built-In group and how can we limit its usage, we can proceed to specific delegations. Those specific delegations, if any, were created by an administrator, with a very good intention but lacking a plan. A plan which should include a Delegation Model based on the least privileged access. To be more clear, if a user needs to change group membership on the XYZ organizational using, then why to delegate full control on groups, or in users, or any other OU than the one mentioned. So, we need to identify (search all possible delegation within our domain) and normalize them. If any of those does follow our plan, then is ok.
What we can Achieve by having a Least Privileged Access model
I don’t even have to mention the importance of having a plan, right?
By granting the least amount of privileges and rights, we reduce the attack surface of our domain.
We have a clear overview of who is doing what, instead of just relying on general purpose built-in groups.
Working among the “Segregation of Duties”, we can audit each of the given roles.
